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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server 
(http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document defines the coding of information in an extension of the Base Station System Application Part 
(BSSAP) that is needed to support location services on interfaces based on use of BSSAP. 

The contents of the present document are subject to continuing work within SMG and TlPl and may change following 
formal SMG and TlPl approval. Should SMG or TlPl modify the contents of the present document it will then be 
re-issued with an identifying change of release date and an increase in version number as follows: 

Version 7.x.y 

where: 

7 GSM Phase 2+ Release 1998; 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc.; 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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Scope 



The present document specifies procedures and information coding that are needed to define and support the BSSAP 
LCS Extension (BSSAP-LE). The BSSAP-LE message set is appHcable to the following GSM interfaces defined in 

GSM 03.71: 

Lb interface (BSC-SMLC) 

Ls interface (MSC-SMLC) 

Lp interface (SMLC-SMLC) 

The present document defines message formats and encoding for BSSAP-LE and the particular subsets of it that are 
applicable to each of the above interfaces. The present document also defines the support for BSSAP-LE message 
transfer on each of these interfaces using CCITT and ANSI versions of SS7 MTP and SCCP. Additional requirements 
for the above interfaces that are applicable to BSSAP-LE are also defined - e.g. usage of BSSAP (as defined in GSM 
04.08 and 08.08) on the Lb interface. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or non- 
specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the 
same number. 

• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y). 

[1] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 03.71: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); 

(Functional description) - Stage 2" 

[3] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 

3 specification". 

[4] GSM 04.31: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); 

Mobile Station (MS) - Serving Mobile Location Center (SMLC); Radio Resource LCS Protocol 
(RRLP)." 

[5] GSM 04.71: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 

3 Location Services (LCS) specification". 

[6] GSM 08.06: " Digital cellular telecommunications system (Phase 2+); Signaling transport 

specification mechanism for the Base Station Subsystem - Mobile-services Switching Centre 
(BSS-MSC) interface". 

[7] GSM 08.08: " Digital cellular telecommunications system (Phase 2+); Mobile-services Switching 

Centre - Base Station System (MSC-BSS) interface; Layer 3 specification" 

[8] GSM 08.31: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); 

Serving Mobile Location Center (SMLC) - Serving Mobile Location Center (SMLC); SMLC Peer 
Protocol (SMLCPP)." 
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[9] GSM 08.71: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); 

Serving Mobile Location Center - Base Station Subsystem (SMLC-BSS) interface Layer 3 
specification." 

[10] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part 

(MAP) specification". 

[11] CCITT Recommendation Q.702: "Specifications of Signalling System No. 7 - Signalling data 

Hnk". 

[12] CCITT Recommendation Q.703: "Signalling link". 

[13] CCITT Recommendation Q.704: "Signalling network functions and messages". 

[14] CCITT Recommendation Q.707: "Specifications of Signalling System No. 7 - Testing and 

maintenance". 

[15] CCITT Recommendation Q.711: "Functional description of the signalling connection control 

part". 

[16] CCITT Recommendation Q.712: "Definition and function of SCCP messages". 

[17] CCITT Recommendation Q.713: "SCCP formats and codes". 

[18] CCITT Recommendation Q.714: "Signalling connection control part procedures". 

[19] ANSI Tl.l 1 1-1996 - SignalHng System Number 7 (SS7) - Message Transfer Part (MTP) 

[20] ANSI Tl.l 12-1996 - SignalUng System Number 7 (SS7) - Signalling Connection Control Part 

(SCCP). 



3 Definitions, symbols and abbreviations 

Unless listed below, all definitions, symbols and abbreviations used in the present document are listed in GSM 01.04 
and GSM 03.71. 



Definition of BSSAP-LE 



BSSAP-LE is an extension to BSSAP that contains messages and parameters specific to the support of LCS. The 
following subsets of BSSAP-LE are defined: DTAP-LE, BSSMAP-LE. 



4.1 DTAP-LE Messages 



DTAP-LEmessages are transfered between an SMLC and a Type A LMU and comprise the following individual 

messages: 

REGISTER 
FACILITY 

RELEASE COMPLETE 
The content, encoding and certain procedures asssociated with DTAP-LE messages are defined in GSM 04.71. 



4.2 BSSIVIAP-LE Messages 



BSSMAP-LE messages are transferred between a BSC, MSC and SMLC and comprise the following individual 

messages: 

BSSMAP-LE Positioning Messages 
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Perform Location Request 

Perform Location Response 

Perform Location Abort 
BSSMAP-LE LMU Control Messages 

LMU Connection Request 

LMU Connection Accept 

LMU Connection Reject 

LMU Connection Release 
BSSMAP-LE Information Messages 

Connection Oriented Information 

Connectionless Information 
The content and encoding of BSSMAP-LE messages are defined in this specification. 

5 Procedures applicable to use of BSSAP-LE 



5.1 Location Request 



The Location Request procedure is applicable to the Lb and Ls interfaces. Its purpose is to obtain a location estimate for 
a target MS that is already in dedicated mode. It is also used to provide an MS with LCS assistance data or with a 
deciphering key for LCS broadcast assistance data. The initiator of a location request may be either the serving BSC or 
the visited MSC for the MS. The procedure makes use of SCCP connection oriented signaling on the Lb and Ls 
interfaces. 

5.1.1 Successful Operation 

The initiator of the location request (VMSC or serving BSC) sends a BSSMAP-LE Perform Location Request to the 
SMLC associated with the current serving cell for the target MS. The message contains the following mandatory (M), 
conditional (C) and optional (O) information, where conditional parameters are required if available. 

Location Type (M) 

Cell Identifier (M) 

Classmark Information Type 3 (C) 

LCS Client Type (O) 

Chosen Channel (C) 

LCS Priority (C) 

LCS QoS (C) 

Requested GPS Assistance Data (C) 

BSSLAP APDU (C) 
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If requested, the SMLC performs positioning of the target MS using a particular position method or a combination of 
more than one positioning method. Ahernatively, if requested otherwise, the SMLC may provide positioning assistance 
data to the MS. The SMLC may invoke the following other BSSAP-LE procedures to perform these procedures: 

connection oriented information transfer 

connectionless information transfer 

LMU connection establishment 

LMU connection release 

DTAP-LE information transfer 

For an SMLC accessed over the Lb interface by a BSC initiator, additional procedures defined in GSM 04.08 and GSM 
08.08 may also be performed. If a location estimate was requested and was subsequently obtained satisfying the 
required LCS QoS, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location 
request (serving BSC or VMSC). This message contains the following mandatory, conditional and optional parameters. 

Location Estimate (M) 

Positioning Data (C) 

If assistance data was instead requested for an MS and the SMLC was able successfully to transfer this to the MS, the 
SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC or 
VMSC). This message shall contain no parameters. The absence of an LCS Cause parameter in this case implies that 
the transfer was successful. 

Otherwise, if a deciphering key was requested for LCS broadcast assistance data and the SMLC has access to the 
appropriate keys, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location 
request (serving BSC or VMSC). This message contains the following mandatory parameters. 

Deciphering Keys (M) 

5.1.2 Unsuccessful Operation 

If the SMLC is unable to obtain any of the location information requested or none of the information obtained satisfies 
the requested LCS QoS or if requested LCS assistance data could not be transferred or requested deciphering keys for 
broadcast assistance data could not be returned, the SMLC shall return a BSSMAP-LE Perform Location Response to 
the initiator of the Location Request carrying the following parameters: 

LCS Cause (M) 

Positioning Data (O) 

5.1.3 Abnormal Conditions 

If an ongoing location request is preempted at the initiator by an inter-BSC handover or if the main signaling link to the 
target MS is lost or released or if there is a timeout waiting for the positioning response, the initiator shall send a 
BSSMAP-LE Perform Location Abort to the SMLC containing the following parameters. 

LCS Cause (M) 

On receipt of this message, the SMLC shall stop positioning of the target MS and may release any resources (e.g. 
LMUs) previously allocated. If the SMLC has not yet returned a BSSMAP-LE Perform Location Response to the 
initiator, it shall return this message containing an LCS Cause indicating an abort and, optionally, positioning data. The 
initiator shall then release the SCCP connection. If the SMLC cannot proceed with positioning due to some protocol 
violation or error condition (e.g. inter-BSC handover indication received from the serving BSC), it shall return a 
BSSMAP-LE Perform Location Response to the initiator containing an LCS cause and, optionally, positioning data. 
The initiator need not reply at the BSSAP-LE level to this message. However, the initiator may return a BSSMAP-LE 
perform Location Abort which shall not be treated as an error by the SMLC. 
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5.2 Connection Oriented Information Transfer 

The Connection Oriented Information transfer procedure is applicable to the Lb and Ls interfaces. It enables both way 
transfer of BSSLAP messages between an SMLC and the BSC serving a target MS. The initiator of the procedure can 
be either the BSC serving the target MS, the visited MSC for the target MS or the SMLC. The procedure is only valid 
while a location request procedure for the target MS is ongoing. The procedure makes use of SCCP connection oriented 
signaling on the Lb and Ls interfaces and uses the same SCCP connection as the location request procedure for the 
particular target MS. 

5.2.1 Successful Operation 

An SMLC, MSC or BSC with a BSSLAP message or message segment to transfer concerning a particular target MS 
sends a BSSMAP-LE Connection Oriented Information message to a recipient carrying the following parameters: 

BSSLAP APDU (M) 

If the sender is an NSS based SMLC, the message is transferred to the VMSC for the target MS. The recipient MSC 
shall then transfer the message to the serving BSC using procedures defined in GSM 08.08. 

If the sender is a BSS based SMLC, the message is transferred to the serving BSC for the target MS. The BSC shall 
then perform the positioning operation requested by the BSSLAP APDU (refer to GSM 08.71). If the BSSLAP APDU 
contains an RRLP APDU, the BSC shall transfer this to the target MS. 

If the sender is a BSC or MSC and the intended recipient is the SMLC for a target MS, the message is transferred to the 
SMLC. The SMLC shall then perform interpretation of the BSSLAP APDU. 

5.2.2 Abnormal ConcJitions 

At an intermediate entity, if a received BSSMAP-LE Connection Oriented Information message contains unrecognized 
information or if the message cannot be sent on, the message shall be discarded. 

At the receipient entity, if a received BSSMAP-LE Connectioin Oriented Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, any ongoing positioning procedure shall be terminated and 
associated resources may be released. If the receipient is a BSC, the SMLC shall be notified - e.g. using a BSSLAP 
Reject or Abort. If the receipient is an SMLC, a new positioning attempt (e.g. using a different position method) may be 
started. 

5.3 Connectionless Information Transfer 

The Connectionless Information transfer procedure is applicable to the Lb, Ls and Lp interfaces. It enables both way 
transfer of LLP messages between an SMLC and a Type B LMU. The procedure also enables both way transfer of 
SMLCPP messages between two SMLCs. The initiator of the procedure can be a BSC, MSC or SMLC. The procedure 
makes use of SCCP connectionless signaling. 

5.3.1 Successful Operation 

An SMLC, MSC or BSC needing to transfer an LLP message concerning a Type B LMU or an SMLCPP message 
sends a BSSMAP-LE Connectionless Information message to a recipient carrying the following parameters: 

Source Entity (M) 

Destination Entity (M) 

Return Error Request (O) 

APDU (M) 

The source entity identifies the sender. The recipient entity identifies the final destination. The Return Error Request 
may be included to request notification in the event of unsuccessful transfer. If the recipient entity is not the final 
destination, the recipient shall transfer the BSSMAP-LE Connectionless Information message to either the final 
destination or an intermediate MSC or BSC capable of onward transfer to the final destination. 
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5.3.2 Unsuccessful Operation 



If the message cannot be transferred by an intermediate entity and the Return Error Request is not included, the 
message shall be discarded. If the Return Error Request is included, the intermediate entity shall send a BSSMAP-LE 
Connectionless Information message to, or towards, the original source containing the following parameters: 

Source Entity (M) 

Destination Entity (M) 

Return Error Cause (M) 

APDU (C) 

The Source entity shall indicate the Destination Entity in the original received message. The Destination Entity shall 
indicate the Source Entity in the original message. The Return Error cause shall indicate the reason for unsuccessful 
transfer. The APDU shall contain any originally received APDU. 

If a received BSSMAP-LE Connectionless Information message containing a Return Error Cause cannot be transferred 
by an intermediate entity, it shall be discarded with no return error message. 

5.3.3 Abnormal ConcJitions 

At an intermediate entity, if a received BSSMAP-LE Connectionless Information message contains unrecognized or 
invalid information, the message shall be discarded. 

At the recipient entity, if a received BSSMAP-LE Connectioinless Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, the message shall be discarded. 

5.4 LMU Connection Establishment 

The LMU Connection Establishment procedure is applicable to the Ls interface. Its purpose is to establish a signaling 
connection between an SMLC and Type A LMU via the visted MSC for the LMU. The procedure can be initiated by 
either the SMLC or MSC. The procedure makes use of SCCP connection oriented signaling on the Ls interface. 

5.4.1 LIVIU Connection Establishment initiated by the SMLC 
5.4.1.1 Successful Operation 

The SMLC sends a BSSMAP-LE LMU Connection Request message to the VMSC for the LMU. This message 
contains the following parameters. 

IMSI (M) 

Sender Address (O) 

Security (C) 

The IMSI identifies the LMU. The sender address, if included, identifies the SMLC. The Security parameter shall be 
included if authentication or ciphering of the LMU are required. On receipt of this message, the MSC shall attempt to 
establish a signalling link to the LMU (refer to GSM 03.71). Authentication and ciphering shall be invoked if requested 
by the SMLC. Once the signaling link has been established, the MSC shall return a BSSMAP-LE LMU Connection 
Accept to the SMLC with the following parameters. 

Call Number (O) 

The call number shall be included if the MSC has the capability to support signaling to an LMU using a traffic channel 
(refer to GSM 03.71). 
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5.4.1 .2 Unsuccessful Operation 

If the LMU is not recognized in the MSC (e.g. no VLR record) or a signaling link cannot be setup to the LMU (e.g. 
paging of the LMU fails) or authentication or ciphering cannot be performed when requested by the SMLC, any 
signaling link to the LMU shall be released, if not required for other MM or CM procedures and a BSSMAP-LE LMU 
Connection Reject shall be returned to the SMLC with the following parameters. 

Reject Cause (M) 

5.4.1.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 

5.4.2 LMU Connection Establishment initiatecJ by the MSC 

5.4.2.1 Successful Operation 

The MSC shall initiate the LMU connection establishment procedure when no LMU connection to the SMLC currently 
exists and the MSC receives a CM Service Request from the LMU specifying the LCS service. The MSC shall then 
send a BSSMAP-LE LMU Connection Request message to the SMLC associated with either the IMSI or current cell 
location of the LMU. This message shall contain the following parameters. 

IMSI (M) 

Sender Address (M) 

Call Number (C) 

The IMSI identifies the LMU. The sender address identifies the MSC. The call number shall be included if the MSC 
has the capability to support signaling to an LMU using a traffic channel (refer to GSM 03.71). On receipt of this 
message, the SMLC shall return a BSSMAP-LE LMU Connection Accept to the MSC with the following parameters. 

Security (C) 

The Security parameter shall be included if authentication or ciphering of the LMU are required On receipt of this 
message, the MSC shall perform authentication and/or ciphering if requested by the SMLC and shall complete the 
establishment of an MM connection to the LMU to support LCS. 

5.4.2.2 Unsuccessful Operation 

If the LMU is not recognized in the SMLC or a signaling connection cannot be supported (e.g. due to congestion), a 
BSSMAP-LE LMU Connection Reject shall be returned to the MSC with the following parameters. 

Reject Cause (M) 

The MSC shall then reject the CM service request from the LMU. 

5.4.2.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 

5.5 LMU Connection Release 

The LMU Connection Release procedure is applicable to the Ls interface. Its purpose is to release a signaling 
connection between an SMLC and Type A LMU. The procedure can be initiated by either the SMLC or MSC. The 
procedure makes use of SCCP connection oriented signaling on the Ls interface. 
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5.5.1 LMU Connection Release initiatecj by the SMLC 

5.5.1.1 Successful Operation 

The SMLC sends a BSSMAP-LE LMU Connection Release message to the VMSC for the LMU. This message 
contains the following parameters. 

Release Cause (M) 

On receipt of this message, the MSC shall release the main signaling link to the LMU unless required for other ongoing 
MM and CM procedures in the MSC. The MSC shall also initiate release of the SCCP connection to the SMLC for the 
LMU. 

5.5.1.2 Abnormal Conditions 

The SMLC may initiate release of the signaling connection to an LMU by initiating release of the SCCP connection for 
the LMU to the MSC. The MSC shall then release the main signaling link to the LMU unless required for other ongoing 
MM or CM procedures. 

5.5.2 LMU Connection Release initiatecj by the MSC 

5.5.2.1 Successful Operation 

The MSC shall initiate release of an LMU connection to an SMLC if the main signaling link to the LMU is released. 
The MSC sends a BSSMAP-LE LMU Connection Release message to the SMLC for the LMU. This message contains 
the following parameters. 

Release Cause (M) 

On receipt of this message, the SMLC should initiate release of the SCCP connection to the MSC for the LMU. 

5.5.2.2 Abnormal Conditions 

The MSC may initiate release of the signaling connection between an SMLC and LMU by initiating release of the 
SCCP connection for the LMU to the SMLC. 

5.6 DTAP-LE Information Transfer 

The DTAP-LE Information transfer procedure is applicable to the Ls interface. It supports bothway LLP message 
transfer between an NSS based SMLC and Type A LMU. The procedure is only valid when a signaling connection 
between an SMLC and Type A LMU has been established. The procedure uses SCCP connection oriented signaling 
using the SCCP connection previously established between the SMLC and MSC when the signaling connection 
between the SMLC and LMU was established. 

5.6.1 DTAP-LE Information Transfer Initiated by the SMLC 

The SMLC initiates the procedure when it has an LLP message to transfer to a type A LMU. The message may first be 
segmented. The SMLC shall then transfer each LLP segment to the MSC inside a DTAP-LE REGISTER, FACILITY 
or RELEASE COMPLETE message. The usage of these messages is as defined in GSM 04.71. The MSC relays each 
DTAP-LE message to the LMU. 

5.6.2 DTAP-LE Information Transfer Initiated by the MSC 

The MSC initiates the procedure when a DTAP message is received from an LMU containing the LCS protocol 
discriminator. The MSC then relays the DTAP message to the SMLC 
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6 Usage of BSSAP-LE and BSSAP on the Lb Interface 

6.1 Applicable Message Sets 

The following BSSAP-LE message sets are applicable to the Lb interface between an SMLC and BSC: 

All DTAP-LE messages 

All BSSMAP-LE positioning messages 

All BSSMAP-LE information messages 

The following BSSMAP messages defined in GSM 08.08 are applicable to the Lb interface to support signaling to a 
Type A LMU using an SDCCH: 

Cipher Mode Command (SMLC to BSC) 

Cipher Mode Complete (BSC to SMLC) 

Cipher Mode Reject (BSC to SMLC) 

Clear Command (BSC to SMLC) 

Clear Complete (BSC to SMLC) 

Clear Request (SMLC to BSC) 

Complete Layer 3 Information (BSC to SMLC) 

Paging (SMLC to BSC) 

The following additional BSSMAP messages defined in GSM 08.08 are applicable to the Lb interface to support 
signaling to a Type A LMU using a TCH: 

Assignment Request (SMLC to BSC) 

Assignment Complete (BSC to SMLC) 

Assignment Failure (BSC to SMLC) 

Block (bothway) 

Blocking Acknowledge (bothway) 

Reset (bothway) 

Reset Ack. (bothway) 

Unblock (bothway) 

Unblocking Ack. (bothway) 

Unequipped circuit (bothway) 

The following DTAP messages defined in GSM 04.08 are applicable to the Lb interface to support signaling to a Type 
A LMU using an SDCCH: 

RR Paging Response 

All MM Messages 
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The following additional CM level DTAP messages defined in GSM 04.08 are applicable to the Lb interface to support 
signaling to a Type A LMU using a TCH. 

Call Confirmed (LMU to SMLC) 

Connect (LMU to SMLC) 

Connect Acknowledge (SMLC to LMU) 

Setup (SMLC to LMU) 

Disconnect (bothway) 

Release (bothway) 

Release Complete (bothway) 

6.2 MTP Functions 

Except where defined otherwise in this specification, MTP requirements on the Lb interface for the BSC are the same 
as those defined for the A interface in GSM 08.06 for the BSC. MTP requirements on the Lb interface for the SMLC 
are the same as those defined for the A interface in GSM 08.06 for the MSC. STP functions are not required in the 
SMLC and a single signaling link set may be used between the BSC and SMLC. The BSC shall be homed to a single 
SMLC and shall only use the Lb signaling interface for signaling communication with the SMLC. 

6.3 SCCP Functions 

6.3.1 General 

Except where defined otherwise in this specification, SCCP requirements on the Lb interface for the BSC are the same 
as those defined for the A interface in GSM 08.06 for the BSC. SCCP requirements on the Lb interface for the SMLC 
are the same as those defined for the A interface in GSM 08.06 for the MSC. Requirements concerning support of a 
type A LMU are the same as those in GSM 08.06 regarding support of a normal MS. In particular, usage of SCCP to 
transfer DTAP-LE messages between a type A LMU and SMLC are the same as those regarding transfer of other 
DTAP messages. 

6.3.2 IVIodifications for Connectionless SCCP 

Connectionless SCCP messages and procedures are used to transfer BSSMAP-LE Connectionless Information 
messages and those BSSMAP messages applicable to the Lb interface for which connectionless SCCP transfer is 
defined in GSM 08.08. Refer to GSM 03.71 for a description of the procedures in the SMLC and BSC. SCCP protocol 
class 1 shall be used when multiple BSSMAP-LE messages are transferred containing segments of a single fragmented 
LLP or SMLCPP message. 

6.3.3 Modifications for Connection Oriented SCCP 

Use of connection oriented SCCP messages and procedures on the Lb interfaces to support signaling access to a type A 
LMU using DTAP-LE, DTAP and BSSMAP messages is the same as that defined in GSM 08.06 on the A interface to 
support access to a normal MS. 

To support positioning of a target MS, connection oriented SCCP messages and procedures using protocol class 2 shall 
be used to transfer BSSMAP-LE positioning messages and BSSMAP-LE Connection Oriented Information messages 
over the Lb interface. A separate dedicated SCCP connection shall be used to support positioning for each target MS. 
Connection establishment shall be instigated by the BSC when the positioning attempt commences. Connection release 
shall be instigated by either the BSC or SMLC when the positioning attempt has been completed or has failed. 

Transfer of BSSMAP-LE messages using an SCCP connection to support positioning of a particular target MS is 
shown in the following figure. In particular, a BSSMAP-LE message shall be included in the data field of the SCCP 
CR and a BSSMAP-LE message may be included in the data field of an SCCP CC, CREF or RLSD message. 
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BSC 



SMLC 



1. SCCP CR [BSSMAP-LE message] 



2. SCCP CREF [BSSMAP-LE message or no data] 
OR 



^ 






2 


. SCCP CC [BSSMAP-LE message or no 


data] 


^ 


3. SCCP DTI [BSSMAP-LE message 


] 


4 


SCCP RLSD [BSSMAP-LE message or no data^ 




5. SCCP RLC 
OR 




4. SCCP RLSD [BSSMAP-LE message or no 


data] 






^ 



5. SCCP RLC 



Figure 6.3.3/09.31 : SCCP Connection Oriented Signaling on Lb Interface for Positioning 

6.3.4 Contents of the SCCP Data Field 

The contents of the SCCP data field are the same as that defined for the A interface in GSM 08.06 for MSC-BSC 
signaling. In particular, the same conventions are used to transfer and discriminate between any BSSAP and DTAP 
message contained within the SCCP data field. Since all BSSAP -LE messages applicable to the Lb interface use the 
same encoding as for the A interface, the conventions used to discriminate a BSSMAP message are applicable to any 
BSSMAP-LE message on the Lb interface, while the conventions for a DTAP message apply to any DTAP-LE 
message. 



7 Use of BSSAP-LE on the Ls Interface 

7.1 Applicable Message Sets 

The following BSSAP-LE messages are applicable to the Ls interface between an MSC and SMLC: 
All DTAP-LE messages 
All BSSMAP-LE positioning messages 
All BSSMAP-LE LMU control messages 
All BSSMAP-LE information messages 
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7.2 MTP Functions 

SS7 signaling on the Ls interface may be supported using 56 kbps or 64 kbps digital signaling channels. These may be 
supported within either El or Tl physical links. 

For El links or where CCITT/ITU SS7 signaling is applicable, the MTP functions as specified in CCITT 
Recommendations Q.702, Q.703, Q.704 and Q.707 are applicable. For Tl links or where ANSI SS7 signaling is 
applicable, the MTP functions as specified in ANSI Tl . 1 1 1 are applicable. For the SMLC, the requirements in these 
recommendations for a signaling end point are applicable. For the MSC, the requirements in these recommendations for 
both a signaling end point and signaling transfer point (STP) are applicable. MSC support of STP functions is only 
required for situations in which the SMLC has no signaling links to an STP and needs to access other network entities 
to which there are no direct point-to-point signaling links. 

Where an SMLC supports direct signaling links to one or more MSCs only and has no signaling links to an STP, certain 
exceptions and modifications to normal CCITT and ANSI requirements may be applied within a PLMN administration. 

7.3 SCCP functions 

7.3.1 General 

For El links or where CCITT/ITU SS7 signaling is applicable, the SCCP functions as specified in either CCITT Blue 
Book Recommendations Q.71 1, Q.712, Q.713 and Q.714 or ITU White Book Recommendations Q.711, Q.712, Q.713 
and Q.714 are applicable, as amended by the exceptions and modifications defined here. For Tl links or where ANSI 
SS7 signaling is applicable, the SCCP functions as specified in ANSI Tl.l 12 are applicable, as amended by the 
exceptions and modifications defined here. 

Several functions of the SCCP are not used on the Ls interface: error detection, receipt confirmation, flow control. 

The segmenting/reassembling function may be used if the total message length exceeds the maximum allowed message 
length that can be carried by the MTP. 

7.3.2 Allowecd Exceptions to CCITT RecommencJations Q.71 1-714 

Only the following SCCP messages are applicable to the Ls interface: 

Connection Confirm (CC) 

Connection Request (CR) 

Connection Refused (CREF) 

Data Form 1 (DTI) 

Inactivity Test (IT) 

Released (RLSD) 

Release Complete (RLC) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes 0, 1 and 2 is required. For protocol class 2, the "credit" parameter field and the 
"sequencing/segmenting" parameter fields are not used, but the parameters must still be included in the Inactivity Test 
(IT) message for syntax reasons. Negotiation of protocol class and flow control is not required for protocol class 2. 



£75/ 



(GSM 09.31 version 7.0.0 Release 1998) 19 ETSI TS 101 530 V7.0.0 (2000-01) 

The SCCP called party address in a CR or UDT may contain only the subsystem number (SSN) or a signaling point 
code (SPC) plus SSN or a global title. Use of a global title is not required for SMLC to MSC signaling within the same 
PLMN. SSN values apphcable to the Ls interface are defined in GSM 03.03. 

For protocol class 2, support of only a single connection section is required. Use of multiple connection sections is a 
national concern. 

7.3.3 Allowed Exceptions to ANSI T1 .11 2 

Only the following SCCP messages are applicable to the Ls interface: 

Connection Confirm (CC) 

Connection Request (CR) 

Connection Refused (CREF) 

Data Form 1 (DTI) 

Inactivity Test (IT) 

Released (RLSD) 

Release Complete (RLC) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes 0, 1 and 2 is required. For protocol class 2, the "credit" parameter field and the 
"sequencing/segmenting" parameter fields are not used, but the parameters must still be included in the Inactivity Test 
(IT) message for syntax reasons. Negotiation of protocol class and flow control is not required for protocol class 2. 

The SCCP called party address in a CR or UDT may contain only the subsystem number (SSN) or a signaling point 
code (SPC) plus SSN or a global title. Use of a global title is not required for SMLC to MSC signaling within the same 
PLMN. SSN values apphcable to the Ls interface are defined in GSM 03.03. 

For protocol class 2, support of only a single connection section is required. Use of multiple connection sections is a 
national concern. 

7.3.4 Usage of Connectionless SCCP 

Connectionless SCCP messages and procedures are used to transfer BSSMAP-LE Connectionless Information 
messages. Refer to GSM 03.71 for a description of the procedures in the SMLC and MSC. SCCP protocol class 1 shall 
be used when multiple BSSMAP-LE messages are transferred containing segments of a single fragmented LLP or 
SMLCPP message. 

7.3.5 Usage of Connection Oriented SCCP 

Connection oriented SCCP messages and procedures for SCCP protocol class 2 shall be used to transfer BSSMAP-LE 
positioning messages, BSSMAP-LE LMU control messages, BSSMAP-LE Connection Oriented Information messages 
and DTAP-LE messages. A separate dedicated SCCP connection shall be used to support either positioning for each 
target MS or signaling to each type A LMU. Connection establishment shall be instigated when the positioning attempt 
commences or when a signaling link to a type A LMU needs to be established. Connection release shall be instigated 
when the positioning attempt has been completed or has failed or when a signaling link to a type A LMU needs to be 
released. The MSC is normally expected to release the SCCP connection to the SMLC. 
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Transfer of BSSAP-LE messages within an SCCP connection is shown in the following figure. In particular, a 
BSSMAP-LE message shall be included in the data field of any SCCP CR and a BSSMAP-LE message may be 
included in the data fields of an SCCP CC, CREF or RLSD message. 













MSC or SMLC 




SMLC or MSC 










^ 






1. SCCP CR [BSSAP-LE message] ^ 


2. SCCP CREF [BSSAP-LE message or no data] 
OR 


2. SCCP CC [BSSAP-LE message or no data] 


^ 3. SCCP DTI [BSSAP-LE message] ^ 


4. SCCP RLSD [BSSAP-LE message or no data] 


5. SCCP RLC 
OR 


4. SCCP RLSD [BSSAP-LE message or no data] 






5. SCCP RLC ^ 



Figure 7.3.5-1/09.31 : SCCP Connection Oriented Signaling on Ls Interface 

7.3.6 Contents of the SCCP Data Field 

The contents of the SCCP data field for BSSMAP-LE and DTAP-LE messages are shown in the following figures. 
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Figure 7.3.6-1/GSM 09.31 : SCCP Data Field for a BSSMAP-LE Message 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 























D=1 


Octet 2 


DLCI 


Octet 3 


Length indicator = n 


Octet 4 

yo 

Octet n+3 


DTAP-LE Message Contents 



Figure 7.3.6-2/GSM 09.31 : SCCP Data Field for a DTAP-LE Message 

The Discrimination Indicator is coded in bit 1 of octet one and indicates the type of the BSSAP-LE message. 
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The DLCI in octet 2 is applicable only to DTAP-LE messages and is coded as defined for the A interface in GSM 08.06 
for DTAP. For signaling to a type A LMU using an SDCCH and SAPI=0, the value of the DLCI is 10000000. 

The length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent 
BSSMAP-LE or DTAP-LE message parameter. 

7.3.7 Content of DTAP-LE Messages 

DTAP-LE messages transferred on the Ls interface are encoded as defined in GSM 04.71. In particular, in octet 1 of 
any DTAP-LE message, the Protocol discriminator shall indicate LCS and the transcation identifier (TI) shall indicate 
the transcation between the SMLC and type A LMU. The TI shall be assigned by the SMLC if the transcation is 
originated from the SMLC and by the LMU if the originator is the LMU. The MSC shall not change the value of the TI 
when transferring any DTAP-LE message from the SMLC to the LMU or from the LMU to the SMLC. 



8 Use of BSSAP-LE on the Lp Interface 

8.1 Applicable Message Sets 

The following BSSAP-LE messages are applicable to the Lp interface between an SMLC and a peer SMLC. 
BSSMAP-LE Connectionless Information message 

8.2 MTP Functions 

SS7 signaling on the Lp interface may be supported using 56 kbps or 64 kbps digital signaling channels. These may be 
supported within either El or TI physical links. 

Two SMLCs may be connected by direct point-to-point SS7 signaling links or links may be employed via intermediate 
STPs. Alternatively, signaling transfer between two SMLCs may be supported via intermediate BSCs and/or MSCs 
using the Lb and/or Ls interfaces. Signaling requirements to support message transfer on the Lp interface via an 
intermediate Lb or Ls interface are the same as those defined elsewhere in this specification for these interfaces. This 
section defines the requirements applicable to direct SMLC-SMLC SS7 links and SS7 links from an SMLC to an STP. 

For El links or where CCITT/ITU SS7 signaling is applicable, the MTP functions as specified in CCITT 
Recommendations Q.702, Q.703, Q.704 and Q.707 are applicable. For TI links or where ANSI SS7 signaling is 
applicable, the MTP functions as specified in ANSI T 1.111 are applicable. Only the requirements in these 
recommendations for a signaling end point are applicable. 

Where an SMLC has no signaling links to an STP, certain exceptions and modifications to normal CCITT and ANSI 
requirements may be applied within a PLMN administration. 

8.3 SCCP functions 
8.3.1 General 

For El links or where CCITT/ITU SS7 signaling is applicable, the SCCP functions as specified in either CCITT Blue 
Book Recommendations Q.71 1, Q.712, Q.713 and Q.714 or ITU White Book Recommendations Q.711, Q.712, Q.713 
and Q.714 are applicable, as amended by the exceptions and modifications defined here. For TI links or where ANSI 
SS7 signaling is applicable, the MTP functions as specified in ANSI Tl.l 12 are applicable, as amended by the 
exceptions and modifications defined here. 
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8.3.2 Allowe(d Exceptions to CCITT Recommen(dations Q.71 1 -71 4 

Only the following SCCP messages are applicable to the Lp interface: 

Inactivity Test (IT) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values applicable to the Lp interface are defined in GSM 03.03. 

8.3.3 Allowed Exceptions to ANSI T1 .11 2 

Only the following SCCP messages are applicable to the Lp interface: 

Inactivity Test (IT) 

Subsystem Allowed (SSA) 

Subsystem Prohibited (SSP) 

Subsystem Status Test (SST) 

Unitdata (UDT) 

Unitdata Service (UDTS) 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values applicable to the Lp interface are defined in GSM 03.03. 

8.3.4 Usage of Connectionless SCCP 

Connectionless SCCP messages and procedures shall be used to transfer BSSMAP-LE Connectionless Information 
messages. Refer to GSM 03.71 for a description of the procedures in the SMLC. SCCP protocol class 1 shall be used 
when multiple BSSMAP-LE messages are sent containing segments of a single fragmented SMLCPP message. 

8.3.5 Usage of Connection Oriented SCCP 

Connection oriented SCCP messages and procedures are not applicable to the Lp interface. 



£75/ 



(GSM 09.31 version 7.0.0 Release 1998) 



23 



ETSI TS 101 530 V7.0.0 (2000-01) 



8.3.6 Contents of the SCCP Data Field 

The contents of the SCCP data field is shown in the following figure. 
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Figure 8.3.6-1/GSI\/l 09.31 : SCCP Data Field for a BSSIVIAP-LE IVIessage 

The Discrmination Indicator is coded in bit 1 of octet one and indicates the type of the BSSAP-LE message. 



Discrminatlon Indicator 





BSSAP-LE IVIessage Type 

BSSIVIAP-LE 



The length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent 
BSSMAP-LE message parameter. 



9 Message Functional Definitions and Contents 

9.1 BSSMAP-LE PERFORM LOCATION REQUEST message 

This message is sent to request a location estimate for a target MS and contains sufficient information to enable location 
according to the required QoS using any positioning method supported by the PLMN and, where necessary, MS. The 
message is also used to request LCS assistance data transfer to an MS or request a deciphering key for LCS broadcast 
assistance data The message can be sent from the BSC to the SMLC and from the MSC to the SMLC. 

Table 9.1 : BSSMAP-LE PERFORM LOCATION REQUEST message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


IVIessage type 


IVIessage Type 
17.1.1.1 


M 


V 


1 


Location Type 


Location Type 


M 


TLV 


4 


Cell Identifier 


Cell Identifier 


M 


TLV 


3-10 


Classmark Information Type 3 


Classmark Information Type 3 


Q 


TLV 


2-n 


LCS Client Type 


LCS Client Type 


Q 


TLV 


3 


Chosen Channel 


Chosen Channel 


Q 


TLV 


n 


LCS Priority 


LCS Priority 


Q 


TLV 


3 


LCS QoS 


LCS QoS 


Q 


TLV 


6 


GPS Assistance Data 


GPS Assistance Data 


Q 


TLV 


3-n 


BSSLAP APDU 


APDU 


Q 


TLV 


2-n 



9.1.1 Location Type 

This parameter defines the type of locatin information being requested. 
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9.1.2 Cell l(dentifier 

This parameter gives the current cell location of the target MS. The format shall either be the cell global identification 
or the LAC plus CI form. 

9.1 .3 Classmark Information Type 3 

This parameter indicates the positioning methods supported by the MS as obtained from the MS Classmark 3 received 
earlier from the target MS. 

9.1.4 LCS Client Type 

This parameter defines the type of the originating LCS Client. It may be included to assist an SMLC to appropriately 
prioritize a location request 

9.1.5 Chosen Channel 

This parameter defines the type of radio channel currently assigned to the target MS. 

9.1.6 LCS Priority 

This parameter defines the priority of the location request. 

9.1.6a LCSQoS 

This parameter provides the required Quality of Service for the LCS Request. Quality of Service may include horizontal 
accuracy, vertical accuracy and allowed response time. 

9.1 .7 GPS Assistance Data 

This parameter identifies the specific GPS assistance data that may be requested. 

9.1.8 BSSLAPAPDU 

This parameter provides additional measurements (e.g. timing advance) for the target MS from the BSC. The 
measurements are contained inside a BSSLAP APDU. 

9.2 BSSMAP-LE PERFORM LOCATION RESPONSE 
message 

This message is sent in response to a BSSMAP-LE Perform Location Request to return a successful location estimate 
for a target MS or to indicate some failure in obtaining this. The message is also sent in response to a BSSMAP-LE 
Perform Location Request to return deciphering keys or an indication that LCS assistance data has been successfully 
delivered to an MS. The message can be sent from the SMLC to the BSC and from the SMLC to the MSC. 



£75/ 



(GSM 09.31 version 7.0.0 Release 1998) 



25 



ETSI TS 101 530 V7.0.0 (2000-01) 



Table 9.2: BSSMAP-LE PERFORM LOCATION RESPONSE message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


IVIessage Type 


M 


V 


1 


Location Estimate 


Geograpliic Location 


C 


TLV 


2-22 


Positioning Data 


Positioning Data 





TLV 


2-n 


Decipliering Key 


Deciphering Key 





TLV 


10-n 


LCS Cause 


LCS Cause 





TLV 


3 



9.2.1 Location Estimate 

This parameter provides a location estimate for the target MS in the case of a successful location attempt. 

9.2.2 Positioning Data 

This parameter provides additional information for the positioning attempt from the SMLC. 

9.2.3 Decipliering Key 

This parameter provides one or more deciphering keys that can be used to decode LCS broadcast assitance data by the 
MS. The SMLC shall provide the current deciphering key for the MS's present location. The SMLC may also provide 
additional deciphering keys applicable either after the current deciphering key or to data broadcast by other SMLCs. 

9.2.4 LCS Cause 

The LCS Cause is included if and only if a requested location estimate was not successfully obtained (e.g. location 
estimate not available or does not meet the required QoS), requested deciphering keys were not successfully returned or 
requested LCS assistance data was not successfully transferred to the MS. The parameter provides the reason for the 
failure. If the LCS Cause is included, the Location Estimate, Current Deciphering Key and Next Deciphering Key shall 
not be included. 

9.3 BSSMAP-LE PERFORM LOCATION ABORT message 

This message is sent by the instigator of a location request to abort the positioning attempt or the request for assistance 
data or deciphering keys. This message can be sent from the MSC to the SMLC and from the BSC to the SMLC. 

Table 9.3: BSSMAP-LE PERFORM LOCATION ABORT message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


IVIessage type 


Message Type 


M 


V 


1 


LCS Cause 


LCS Cause 


M 


TLV 


3 



9.3.1 LCS Cause 

The LCS Cause provides the reason for the aborting the location attempt. 

9.4 BSSMAP-LE LMU CONNECTION REQUEST message 

This message is sent to request the establishment of a signaling connection between an LMU and an SMLC. The 
message can be sent from an SMLC to an MSC and from an MSC to an SMLC. 
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Table 9.4: BSSMAP-LE LMU CONNECTION REQUEST message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


IMSI 


IMSI 


M 


TLV 


3-10 


Sender Address 


Signaling Point Code 





TLV 


2-n 


Security 


Security 





TLV 


2-n 


Call Number 


ISDN Address 





TLV 


3-n 



9.4.1 IMSI 

This parameter identifies the LMU using its E.212 IMSI. 

9.4.2 Sender Address 

This parameter provides the SS7 signaling point code for the sender of the message. The parameter is mandatory for 
message transfer between an MSC and SMLC on the Ls interface. 

9.4.3 Security 

This parameter indicates if authentication or ciphering are required for the LMU. This parameter may be included for 
message transfer from an SMLC. If the parameter is absent, authentication and ciphering shall be assumed not to be 
required. 

9.4.4 Call Number 

This parameter may be included in an LMU connection request sent by an MSC to enable the SMLC to subsequently 
establish a TCH to the LMU. 

9.5 BSSMAP-LE LMU CONNECTION ACCEPT message 

This message is sent in response to a BSSMAP-LE LMU Connection Request message to accept the establishment of a 
signaling connection between an LMU and an SMLC. The message can be sent from an SMLC to an MSC and from an 
MSC to an SMLC. 

Table 9.5: BSSMAP-LE LMU CONNECTION ACCEPT message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Security 


Security 





TLV 


3 


Call Number 


ISDN Address 





TLV 


3-n 



9.5.1 Security 

This parameter indicates if authentication or ciphering are required for the LMU. This parameter may be included for 
message transfer from an SMLC. If the parameter is absent, authentication and ciphering shall be assumed not to be 
required. 
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9.5.2 Call Number 

This parameter may be included in an LMU connection accept sent by an MSC to enable the SMLC to subsequently 
estabhsh a TCH to the LMU. 

9.6 BSSMAP-LE LMU CONNECTION REJECT message 

This message is sent in response to a BSSMAP-LE LMU Connection Request message to reject the establishment of a 
signaling connection between an LMU and an SMLC. The message can be sent from an SMLC to an MSC and from an 
MSC to an SMLC. 

Table 9.6: BSSMAP-LE LMU CONNECTION REQUEST message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Reject Cause 


LMU Cause 


M 


TLV 


3-10 



9.6.1 Reject Cause 

This parameter provides the reason for the rejection of an LMU connection. 

9.7 BSSMAP-LE LMU CONNECTION RELEASE message 

This message is sent to release a signaling connection between an LMU and an SMLC. The message can be sent from 
an SMLC to an MSC and from an MSC to an SMLC. 

Table 9.7: BSSMAP-LE LMU CONNECTION RELEASE message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Release Cause 


LMU Cause 


M 


TLV 


3-10 



9.7.1 Release Cause 

This parameter provides the reason for the release of an LMU connection. 

9.8 BSSMAP-LE CONNECTION ORIENTED INFORMATION 
message 

This message is sent in association with an existing signaling connection between an SMLC and another enity to 
transfer information between the SMLC and other entity belonging to a higher level protocol. The message can be sent 
from an SMLC to an MSC, from an MSC to an SMLC, from a BSC to an SMLC and from an SMLC to a BSC. 



£75/ 



(GSM 09.31 version 7.0.0 Release 1998) 



28 



ETSI TS 101 530 V7.0.0 (2000-01) 



Table 9.8: BSSMAP-LE CONNECTION ORIENTED INFORMATION message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


BSSLAP APDU 


APDU 


M 


TLV 


3-n 



9.8.1 BSSLAP APDU 

This parameter contains a BSSLAP message. 

9.9 BSSMAP-LE CONNECTIONLESS INFORMATION 
message 

This message conveys signaling information associated with a higher protocol level between an SMLC and another 
enity when there is no existing signaling connection association. The message can be sent from an SMLC to an MSC, 
from an MSC to an SMLC, from a BSC to an SMLC, from an SMLC to a BSC and from an SMLC to another SMLC, 

Table 9.9: BSSMAP-LE CONNECTIONLESS INFORMATION message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Source Identity 


Networl< Element Identity 


M 


TLV 


3-n 


Destination Identity 


Network Element Identity 


M 


TLV 


3-n 


APDU 


APDU 





TLV 


3-n 


Return Error Request 


Return Error Request 





TLV 


2 


Return Error Cause 


Return Error Cause 





TLV 


3 



9.9.1 Source Identity 

This parameter identifies the original source of the message. The original source can either be an SMLC or a Type B 
LMU. The source is identified by association with either a location area or a cell site. 

9.9.2 Destination Identity 

This parameter identifies the final destination of the message. The final destination can either be an SMLC or a Type B 
LMU. The destination is identified by association with either a location area or a cell site. 

9.9.3 APDU 

This parameter contains an embedded APDU. For information transfer between an SMLC and Type B LMU this shall 
be an LLP APDU. For information transfer between two peer SMLCs, this shall be an SMLCPP APDU. 

9.9.4 Return Error Request 

This pareameter may be included to request an error response if BSSMAP-LE message cannot be delivered successfully 
to its final destination. This parameter shall not be included if the Return Error cause is present. 
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9.9.5 Return Error Cause 

This parameter indicates an error response for a BSSMAP-LE connectionless information message that could not be 
delivered to its final destination. The APDU should be present and the same as the APDU in the original undelivered 
message. The source and destination identies shall be included and the same as the destination and source identities, 
respectively, in the original undelivered message. 



1 Message format and information element coding 

This clause specifies the coding of the Information Elements used by the BSSAP-LE protocol. The spare bits in the 
coding of an IE shall be set to zero by the sender and shall be ignored by the receiver. 

All unassigned codes (whether omitted or explicitely Unassigned in the text) shall be treated as unknown (see clause 
'Error Handling and Future Compatibility'). 

The following conventions are assumed for the sequence of transmission of bits and bytes: 

Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first. 

In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet 
of the field. 

For variable length elements a length indicator is included, this indicates the number of octets following in the 
element. 

All fields within Information Elements are mandatory unless otherwise specified. The Information Element 
Identifier shall always be included. 

All spare bits are set to 0. 

For any information element of format TLV, the length indicator octet, as in GSM 08.08, defines the number of octets 
in the information element that follow the length indicator octet. 



10.1 IVIessage type 



Message type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages. 
Table 10.1/GSM 09.31 : Message type information element 



Category 



8 7 6 5 4 3 2 1 Message Type 



POSITIONING MESSAGES 



LMU CONTROL MESSAGES 



INFORMATION MESSAGES 



00000000 Reserved. 

10 10 11 BSSMAP-LE PERFORM LOCATION REQUEST 

10 110 1 BSSMAP-LE PERFORM LOCATION RESPONSE 

10 1110 BSSMAP-LE PERFORM LOCATION ABORT 

00000000 BSSMAP-LE LMU CONNECTION REQUEST 

1 BSSMAP-LE LMU CONNECTION ACCEPT 

10 BSSMAP-LE LMU CONNECTION REJECT 

1 1 BSSMAP-LE LMU CONNECTION RELEASE 

10 10 10 BSSMAP-LE CONNECTION ORIENTED INFORMATION 

1110 10 BSSMAP-LE CONNECTIONLESS INFORMATION 
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10.2 Information Element Identifiers 

The next list shows the coding of the Information Element Identifiers used in the present document. 
Table 10.2/GSM 09.31: Information Element Identifier coding 



87654321 


Information element 


Reference 


00111110 


LCS QoS 


10.15 


00111111 


LCS Priority 


10.14 


010000 11 


Location Type 


10.16 


01000100 


Geographic Location 


10.8 


01000101 


Positioning Data 


10.18 


01000110 


LCS Cause 


10.12 


01000111 


LCS Client Type 


10.13 


01001000 


APDU 


10.3 


01001001 


Networl< Element Identity 


10.17 


01001010 


GPS Assistance Data 


10.9 


010010 11 


Deciphering Key 


10.7 


01001100 


Return Error Request 


10.19 


01001101 


Return Error Cause 


10.20 


000100 11 


Classmark Information Type 3 


10.6 


00000101 


Cell Identifier 


10.4 


00 100001 


Chosen Channel 


10.5 


00000000 


IMSI 


10.10 


00000001 


ISDN Address 


10.11 


000000 10 


Security 


10.21 


000000 1 1 


Signaling Point Code 


10.22 



8 7 


1 6 


1 5 1 4 1 3 1 2 1 1 1 


lEI 


Length indicator 


S 




Protocol ID 1 


The rest of the information element contains a message whose 
content and encoding are defined according to the protocol ID. 



10.3 APDU 

This is a variable length information element that conveys an embedded message or message segment associated with a 
higher level protocol. 

Octet 1 
Octet 2 
Octet 3 
Octet 4 

to 
Octet n 

Figure 10.3.1/GSM 09.31: APDU IE 

Protocol ID (bits 7-1 of octet 3) 

0000000 reserved 

0000001 BSSLAP 

0000010 LLP 

0000011 SMLCPP 
S (Segmentation Bit, bit 8 of octet 3) 

final segment in a segmented message or a non-segmented message or segmenting not indicated 

1 non-final segment in a segmented message 
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Embedded Message (octets 4-n) 

BSSLAP the embedded message is as defined in GSM 08.71 

LLP the embedded message contains a Facility Information Element as defined in GSIVI 04.71 excluding 

the Facility lEI and length of Facility lEI octets defined in GSIVI 04.71 . 

SMLCPP the embedded message is as defined in GSIVI 08.31 



10.4 Cell Identifier 

This is a variable length information element identifying a particular cell. 



Octet 1 
Octet 2 
Octet 3 



8 7 


1 6 1 5 1 4 1 


3 


2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded 
the Cell Identifier IE defined in GSIVI 08.08. 


as the 


value part of 



Figure 10.4.1/GSI\/I 09.31 : Cell Identifier IE 



10.5 Chosen Channel 



This information element identifiers a type of radio interface channel. 



Octet 1 
Octet 2 
Octet 3 



8 7 


6 5 4 3 


2 1 


lEI 


Length indicator 


The rest of the information element is coded as 
the Chosen Channel IE defined in GSIVI 08.08. 


the value part of 



Figure 10.5.1/GSM 09.31: Chosen Channel IE 



1 0.6 Classmark Information Type 3 



This information element contains classmark information for a target MS obtained from the MS Classmark 3 defined in 
GSM 04.08. 



Octet 1 
Octet 2 
Octet 3 



8 7 


1 6 1 5 1 4 1 


3 1 2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded 
the Classmark Information Type 3 IE defined 


as the value part of 
in GSIVI 08.08. 



Figure 10.6.1/GSM 09.31 : Classmark Information Type 3 IE 
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10.7 Deciphering Keys 



This information element defines the deciphering keys which should used by the MS to decode LCS broadcast 
assistance data. The parameter includes following data fields: 





8 


7 


6 5 4 3 


2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


spare 


Ciphering 
Key Flag 


Octet 4 
Octet 10 


Current Deciphering Key Value 


Octet 1 1 
Octet 17 


Next Deciphering Key Value 



Figure 10.7.1/GSI\/I 09.31: Deciphering Keys IE 



Ciphering Key Flag (octet 3) 



This flag indicates indicates the current Ciphering Key Flag used in the LCS assistance data broadcast messages in the 
location area. 

Current Deciphering Key Value (octet 4 - 10) 

Current Deciphering Key contains the 56 bit deciphering key that is currently in use in location area for deciphering the 
LCS assistance data broadcast messages. 

Next Deciphering Key (octet 11-17) 

Next Deciphering Key contains the 56 bit deciphering key that will be used next in location area for deciphering the 
LCS assistance data broadcast messages.. 



10.8 Geographic Location 



This is a variable length information element providing an estimate of a geographic location. 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 
to 
Octet n 


The rest of the information element contains an octet sequence 
identical to that for the Ext-Geographicallnformation data type in 
GSM 09.02. 



Figure lO.S.I/GSIVI 09.31: Geographic Location IE 



1 0.9 GPS Assistance Data 

This is a variable length information element identifying the GPS assistance data requested for an MS. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 

to 
Octet 
8+2n 



8 


7 


1 6 1 5 1 4 1 3 


2 


1 1 


IE! 


Length indicator 


spare Eph 


ACQ 


SAT 1 


Satellite related data 



Figure 10.9.1/GSM 09.31 : GPS Assistance Data IE 
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SAT - Satellite related data (bit 1 of octet 3) 

: Satellite related data is not requested - octets 4 to 8+2n are not present 

1 : Satellite related data is requested - octets 4 to 8+2n are present 
ACQ - Acquisition Assistance (bit 2 of octet 3) 

: Acquisition Assistance is not requested 

1 : Acquisition Assistance is requested 
Eph - Ephemeris Compression (bit 3 of octet 3) 

This field indicates the compression method for ephemeris update. 

0: Ephemeris compression can be incorporated into requested Navigation Model information. 
1 : Ephemeris compression cannot be incorporated in requested Navigation Model information. 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 4 


H 


G 


F 


E 


D 





B 


A 


Octet 5 


GPS Week 


spare 


Octet 6 


GPS Week 


Octet 7 


GPS_Toe 


Octet 8 


Spare 




NSAT T-Toe limit 


Octet 9 


spare 




SatID 1 






Octet 10 


I0DE1 


... 




Octet 7+2n 


spare 




SatID n 






Octet 8+2n 


lODEn 



Figure 10.9.2/GSI\/I 09.31 : Coding of Satellite Related Data 



Octets 4 and 5 



bit A Almanac 

: Almanac is not requested 

1 : Almanac is requested 

bitB UTC Model 

: UTC Model is not requested 

1 : UTC Model is requested 

bit C Ionospheric Model 

: Ionospheric Model is not requested 

1 : Ionospheric Model is requested 

bit D Navigation Model 

: Navigation Model is not requested 

1 : Navigation Model is requested 

bit E DGPS Corrections 

: DGPS Corrections are not requested 

1 : DGPS Corrections are requested 

bit F Reference Location 

: Reference Location is not requested 

1 : Reference Location is requested 

bit G Reference Time 

: Reference Time is not requested 

1 : Reference Time is requested 

bit H spare 
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At least one of bits A, B, C, D, E, F, or G shall be set to the value "1". 

GPS Week (bits 7-8 octet 5 and octet 6) 

This field contains a 10 bit binary representation of the GPS Week of the assistance currently held by the MS. The most 
significant bit of the GPS Week is bit 8 in octet 5 and the least significant bit is bit 1 in octet 6. 

GPS_Toe (octet 7) 

This field contains a binary representation of the GPS time of ephemeris in hours of the latest ephemeris set contained 
in handset memory (range 0-167). 

NSAT (octet 8, bits 4-7) 

This field containss a binary representation of the number of satellites to be considered for the current GPS assistance 
request. 

T-Toe limit (octet 8, bits 1-3) 

This field contains a binary representation of the ephemeris age tolerance of the MS to the network in hours. 

SatID X (x = 1,2, ... n) (octet 7 + 2x, bits 1-6) 

This field contains a binary representation of the identity of a satellite for which the assistance request is applicable. 
The number of satellite fields is indicated in the field NSAT. 

lODE X (x = 1,2, ... n) (octet 8 + 2x) 

This field contains a binary representation of the Issue of Data Ephemeris, which identifies the sequence number for the 
satellite x (x = 1,2, ..., n). 

10.10 IMSI 

The IMSI is of variable length and is coded as a sequence of BCD digits, compressed two into each octet. This is a 
variable length element, and includes a length indicator. The IMSI is defined in GSM 03.03. It shall not exceed 15 
digits (see GSM 03.03). 





8 7 6 5 


4 


3 


2 


1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


IMSI digit 1 


odd/ 
even 











Octet 4 


IMSI digit 3 


IMSI digit 2 


Octet 4+x 


IMSI digit i+1 


IMSI digit! 



Figure lO.IO.I/GSIVI 09.31: IIVISI IE 

Where x = (i-2)/2 and i is always even 

* The value of the odd/even bit (bit 4 in octect 3) indicates: 

Even number of IMSI digits 

1 Odd number of IMSI digits 

If the number of IMSI digits is even then bits 5 to 8 of the last octet shall be filled with an end mark 
coded as 1111. 
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10.11 ISDN Address 



This information element contains an ISDN address. 



Octet 1 
Octet 2 
Octet 3 



lEI 



Length indicator 



The rest of the information element contains an octet string coded 
the same as the ISDN-AddressString common data type defined in 
GSIVI 09.02 



Figure 10.11. 1/GSIVI 09.31: ISDN Address IE 



10.12 LCS Cause 

The LCS Cause parameter is of variable length IE and provides the reason for an unsuccessful location request. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



NOTE 1 : The inclusion of this octet depends on the cause value 

Figure 10.12.1/GSM 09.31: LCS Cause IE 

Table 10.12.1/GSM 09.31 : Cause value 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


lEI 


Length indicator 


Cause value 


Diagnostic value (note 1) 



LCS Cause value (octet 2) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Data missing in position request 


00000100 


Unexpected data value in position request 


00000101 


Position method failure 


000001 10 


Target MS Unreachable 


000001 1 1 


Location request aborted 


00001000 




to unspecified in this version of the protocol 


11111111 





Diagnostic value (octet 4): 

this octet may be included if the cause value indicates "position method failure", the binary encoding of this 
octet shall encode the same set of values as defined for the PositionMethodFailure-Diagnostic in GSM 09.02. 
Values outside those defined in GSM 09.02 shall be ignored by a receiver. 
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10.13 LCS Client Type 

This information element identifies the type of LCS CHent. 



8 


|7|6|5|4|3|2| 


1 1 


lEI 


Length indicator 


Client Category Client Subtype 



Octet 1 
Octet 2 
Octet 3 



Figure 10.13.1/GSI\fl 09.31 : LCS Client Type IE 

The client category (bits 8-5 of octet 2) and the client subtype (bits 4-1 of octet 2) are coded as follows. 



Client Category 


Client Subtype 


Explanation 


0000 


0000 
all values 


Value Added Client 

unspecified 

reserved 


0010 


0000 
0001 
0010 
0011 
0100 
other values 


PLIVIN operator 

unspecified 

broadcast service 

O&M 

anonymous statistics 

Target MS service support 

reserved 


0011 


0000 
other values 


Emergency services 

unspecified 

reserved 


0100 


0000 
other values 


Lawful Intercept services 

unspecified 

reserved 


0101 -1111 


all values 


reserved 



10.14 LCS Priority 



This information element defines the priority level of a location request. 



Octet 1 
Octet 2 
Octet 3 



8 7 


6 


5 4 3 


2 1 


lEI 


Length indicator 


This octet is 


coded 


as the LCS-Priority octet in 


GSM 09.02. 



Figure 10.14.1/GSM 09.31 : LCS Priority IE 



10.15 LCSQoS 

This information element defines the Quality of Service for a location request. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 
Octet 5 
Octet 6 



8 7 


6 


1 5 1 4 1 3 1 


2 


1 1 


lEI 


Length indicator 


spare 


VERT 1 


HA 


Horizontal Accuracy 


VA 


Vertical Accuracy 


RT 


spare 



Figure 10.15.1/GSM 09.31 : Cell Identifier IE 
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Octet 3 



VERT = vertical coordinate indicator 

: vertical coordinate not requested 

1 : vertical coordinate is requested 

Octet 4 

bit 8 HA = horizontal accuracy indicator 

: Horizontal Accuracy is not specified 

1 : Horizontal Accuracy is specified 

bits 7-1 Horizontal Accuracy : 

spare (set all zeroes) if HA=0 

set to 7 bit uncertainty code in GSM 03.32 if HA=1 

Octet 5 - applicable only if VERT = 1 

bit 8 VA = vertical accuracy indicator 

: Vertical Accuracy is not specified 

1 : Vertical Accuracy is specified 

bits 7-1 Vertical Accuracy : 

spare (set all zeroes) if VA=0 

set to 7 bit uncertainty altitude code in GSM 03.32 if VA=1 



Octet 6 



bits 8-7 RT = response time category 

00 : Response Time is not specified 

01 : Low Delay 

10 : Delay Tolerant 

1 1 : reserved 

bits 6-1 spare 



10.16 Location Type 



This is a variable length information element defining the type of location information being requested. 





8 


7 


6 5 4 3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Location Information 


Octet 4 


Positioning IVIethod 



Figure 10.16.1/GSIUI 09.31: Location Type IE 

Coding of location information (octet 3): 

00000000 current geographic location 

00000001 location assistance information for the target MS 
00000010 deciphering key for broadcast assistance data for the target MS 
all other values are reserved 

Positioning Method (octet 4) 



£75/ 



(GSM 09.31 version 7.0.0 Release 1998) 



38 



ETSI TS 101 530 V7.0.0 (2000-01) 



This octet shall be included if the location information in octet 3 indicates "location assistance information for the target 
MS" and shall be omitted otherwise. 

00000000 reserved 

00000001 Mobile Assisted E-OTD 

00000010 Mobile Based E-OTD 

00000011 GPS 

all other values are reserved 



10.17 Network Element Identity 



8 


7 1 6 


1 5 1 4 1 3 1 2 1 1 1 


lEI 


Length indicator 




spare 


1 Identity Discrminator 


Networl< Element Identification 



This is a variable length information element identifying a network element, by association with either a designated cell 
site or a designated location area. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 

to 
Octet n 



Figure 10.17.1/GSI\/I 09.31: Network Element Identity IE 

Identity Discriminator (bits 4-1 of octet 3) 

0000 Identification using the LAC as defined in GSM 03.03 

0001 Identification using LAC + CI as defined in GSM 03.03 



Octet 4 
Octet 5 



Figure 10.17.2/GSM 09.31 : Coding of Network Element Identification using the LAC 



Octet 4 
Octet 5 
Octet 6 
Octet 7 

Figure 10.17.3/GSM 09.31 : Coding of Network Element Identification using the LAC + CI 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


LAC 


LAC - continued 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


LAC 


LAC - continued 


CI value 


CI value - continued 



10.18 Positioning Data 



This is a variable length information element providing positioning data associated with a successful or unsuccessful 
locatiomn attempt for a target MS. 





8 


7|6|5|4|3|2|1| 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


spare Positioning Data Discriminator 


Octets 4-4+m 


Positioning Method 1 






Octets ..-4+nm 


Positioning Method n 



Figure 10.18.1/GSM 09.31: Positioning Data IE 
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The positioning data discrminator (bits 4-1 of octet 3) defines the type of data provided for each positioning method: 
0000 indicate usage of each positioning method that was attempted either successfully or unsuccessfully 
all other values are reserved 
Coding of the postioning method octets for positioning data discrminator = 0: 



Octet X I positioning method | usage 



Coding of positioning method (bits 8-4): 

00000 Timing Advance 

00001 TOA 

00010 AOA 

00011 Mobile Assisted E-OTD 

00100 Mobile Based E-OTD 

00101 Mobile Assisted GPS 

001 10 Mobile Based GPS 

001 1 1 Conventional GPS 
01000 

to reserved for GSM 

01111 

10000 

to reserved for network specific positioning methods 

11111 

Coding of usage (bits 3-1) 

000 Attempted unsuccessfully due to failure or interruption 

001 Attempted successfully: results not used to generate location 

010 Attempted successfully: results used to verify but not generate location 
Oil Attempted successfully: results used to generate location 

100 Attempted successfully: case where MS supports multiple mobile based positioning methods 
and the actual method or methods used by the MS cannot be determined 



10.19 Return Error Request 
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1 5 1 4 1 
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1 1 


lEI 


Length indicator 



The Return Error Request parameter indicates a request from the source of a BSSMAP-LE connectionless information 
message for an error response if the message cannot be delivered to its final destination. 

Octet 1 
Octet 2 

Figure lO.IS.I/GSIVI 09.31: Return Error Request IE 

10.20 Return Error Cause 

The Return Error Cause parameter provides the reason for unsuccessful delivery of a BSSMAP-LE Connectionless 
Information message to its final destination. 

Octet 1 
Octet 2 
Octet 3 

Figure 10.20. 1/GSIVI 09.31: Return Error Cause IE 
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Table 10.20.1/GSM 09.31 : Cause value 



Cause value (octet 2) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Destination unknown 


00000100 


Destination unreachable 


00000101 


Congestion 


000001 10 




to unspecified in this version of the protocol 


11111111 





10.21 Security 



This information element defines what security measures are needed for signaling to an LMU. 



Octet 1 
Octet 2 
Octet 3 
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spare 


CIPH 


AUTH 



Figure 10.21. 1/GSM 09.31 : Security IE 



Coding of octet 3: 

bit 1 AUTH = authentication indicator 

: authentication of LMU not required 

1 : authentication of LMU required 

bit 2 CIPH = ciphering indicator 

: ciphering of LMU signaling data not required 

1 : ciphering of LMU signaling data required 

1 0.22 Signaling Point Code 

This is a variable length information element providing that provides the signaling point code of a network element. 



Octet 1 

Octet 2 

Octets 3-n 
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Figure 10.22.1/GSM 09.31 : Signaling Point Code IE 



There are three options for the coding of Signaling Point Code value; 2 octets containing a 14 bit ITU code, 3 octets 
containing a 24 bit unstructured code and 3 octets containing a 24 bit ANSI structured code. 

Encoding of 14 bit ITU signaling point code: 



Octet 3 
Octets 4 







signaling point code (high order bits) 



signaling point code (low order bits) 
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Encoding of a 24 bit unstructured signaling point code: 



Octet 3 
Octet 4 
Octets 5 



signaling point code (high order octet) 



signaling point (second octet) 



signaling point code (low order octet) 



Encoding of a 24 bit ANSI structured signaling point code: 



Octet 3 
Octet 4 
Octets 5 



Network Identifier 



Network Cluster 



Network Cluster Member 
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Annex A (informative): 
Change History 



Change history 


Meeting# 


Spec 


Version 


CR 


<Phase> 


New Version 


Subject/Comment 


SMG#30bis 


09.31 




- 


R98 


7.0.0 


Approved at SMG#30bis as Release 98 
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